Bei //SEIBERT/MEDIA arbeiten wir in externen und internen Projekten bevorzugt mit agilen Vorgehensmodellen und Methoden und haben die Vorteile der Zusammenarbeit in Teamräumen mit Visualisierung der wichtigsten Artefakte erkannt. Alle unsere Büros verfügen über Taskboards, auf denen die Teams ihre aktuell anfallenden Aufgaben verwalten und in täglichen Standup-Meetings besprechen, was als nächstes zu tun ist.
Der Fokus des Taskboards liegt dabei auf den Arbeiten, die in den nächsten Tagen oder Wochen abgeschlossen werden sollen. Bei Scrum-Teams ist es der aktuelle Sprint, der dargestelt wird. Was ist aber mit den Aufgaben, die in den nächsten Wochen oder Monaten anstehen? Was hat das Team also mittelfristig zu tun?
Transparenz über mittelfristige Arbeiten: Das Product-Backlog-Board
Wenn in Projekten längerfristig gearbeitet wird – beispielsweise an komplexen Software-Produkten -, empfiehlt sich die Etablierung eines Product-Backlog-Boards.
Zur Erinnerung: Was war noch gleich ein Product Backlog? Grundsätzlich enthält das Product Backlog alle Arbeiten, die zur Erstellung eines erfolgreichen Produkts notwendig sind. Konkret handelt es sich dabei z.B. um neue Funktionalitäten, einfache Aufgaben oder Fehlermeldungen, die das Team zu bearbeiten hat.
Das Product-Backlog-Board ist eine Visualisierung dieses Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, sodass sich alle Teammitglieder und auch die Stakeholder jederzeit darüber informieren können.
Der Aufbau eines Product-Backlog-Boards
Den grundlegenden Aufbau eines Backlog Boards erläutert Roman Pichler in seinem Artikel The Product Backlog Board. Die folgende Darstellung zeigt ein reduziertes Board, an dem auch wir uns orientieren:
Die zentralen Bereiche des Product-Backlog-Boards sind die Story Area und die Constraint Area.
Die Story Area
In der Story Area wird das Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte User-Stories, sondern oft auch um Fehlermeldungen und entdeckte Bugs.
User-Stories sind in drei Granularitätsgraden integriert: Stories, Epics und Themes.
Fein zerteilte Stories, die bereit für die Umsetzung sind, befinden sich oben im Bereich Ready items. Die feine Zergliederung wird dabei vornehmlich für die hochprioren Stories vorgenommen, die nach Möglichkeit im nächsten Sprint eingeplant werden sollen.
Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen zur ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics sind grobe Formulierungen von Features, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung naherückt.
Im Bereich der Ready items ist eine Priorisierung durch den Product Owner Pflicht, während sie nach Pichler im Bereich der Themes & Epics nicht unbedingt erforderlich ist.
Die Constraint Area
In der Constraint Area werden die grundlegenden Anforderungen an die Oberfläche der Software sowie operative Eigenschaften der Anwendung festgehalten.
Das Produkt- und User-Interface-Design kann z.B. in Form von Screenshots, Wireframes und selbst einfachen Skizzen mit Anmerkungen zu den wichtigsten Vereinbarungen dargestellt werden.
Die operativen Eigenschaften lassen sich mithilfe von Constraint Cards abbilden, wobei das Team pro Karte eine bestimmte operative Eigenschaft festhält, beispielsweise die Browser, für die das System zu optimieren ist, die Performance der Software, die Skalierbarkeit usw.
Dabei ist es ratsam, die Constraints mit der Definition of Done zu verknüpfen, damit deren Einhaltung zum Bestandteil der Abnahme jeder einzelnen User-Story wird. Das lässt sich gut am Beispiel der Browser-Optimierung verdeutlichen: Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story auch nicht als "Done".
Regelmäßige Backlog-Pflege
Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog-Grooming-Workshops oder -Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie.
Für Teams mit zweiwöchigen Sprints gilt als Faustregel, zwei Stunden pro Woche mit Backlog-Grooming-Workshops zu verbringen, was 5% der Arbeitszeit einer 40-Stunden-Woche entspricht. Diese Zeit ist gut investiert: Das Team erfährt frühzeitig, was demnächst zu erwarten ist, kann selbst Vorschläge einbringen, Lösungsoptionen können erarbeitet, Risiken für die Umsetzung frühzeitig erkannt und adressiert werden.
Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich größer und die Qualität des Backlogs nimmt erfahrungsgemäß signifikant zu.
Product-Backlog-Board und Software-Unterstützung
Und wie steht es mit der Nutzung elektronischer Hilfsmittel, wenn ein Product Backlog Board erstellt und gepflegt wird? Wir arbeiten mit der professionellen Aufgabenmanagement-Software JIRA und pflegen unseren Backlog in diesem System. Über ein Scrum Cards Plugin können wir kompakte Ausdrucke der Zettel vornehmen, die wir sowohl für unsere Product-Backlog-Boards als auch für die Taskboards nutzen. So können wir die Vorteile elektronischer Systeme und die Vorteile der präsenten Offline-Darstellung mit geringem Mehraufwand verbinden.
Haben Sie Fragen zu agilen Vorgehensweisen? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehr als 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und größten Anbietern für Scrum in Verbindung mit den Atlassian-Tools JIRA/Greenhopper und Confluence in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an.
Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.
Weiterführende Informationen zur Backlog-Pflege
User-Stories: Anforderungen aus Nutzersicht dokumentieren
Card, Conversation, Confirmation: Die drei Cs einer User-Story
User-Stories schreiben ist wie Fahrradfahren
Die besten Ressourcen zu User-Stories
Mehr über die Creative-Commons-Lizenz erfahren